Java-based web applications can be hosted on a variety of application servers, e.g., IBM's WebSphere Application Server (WAS) for z/OS. On WAS for distributed platforms, an application server includes only one address space, which corresponds to a single java virtual machine (JVM). However, on z/OS, an instance of an application server actually includes at least two sets of distinct address spaces. This mismatch creates the potential for errors and incompleteness in system resource monitoring and reporting. FIGS. 1 and 2 below provide context and explanation to illustrate this problem in detail.
FIG. 1 is prior art a schematic diagram of an exemplary WAS architecture 100 for z/OS having an application server 102 and two distinct address spaces 104, 108. The first set of address spaces 104 corresponds to a “controller,” or “controller region,” which receives incoming requests 112 from one or more clients 114 (typically via HTTP), creates a Work Load Manager (WLM) Enclave 116, and queues up the incoming requests 112 to delegate units of work 120 to be completed (e.g., individual units of work 120A, 120B, 120C) to one or more “servants” or “servant regions” (e.g., servants 108A, 108B, 108C) within the server 102. The second set of address spaces 108 corresponds to the one or more servants 108A, 108B, 108C themselves, which are the points of execution of applications (e.g., EJBs, Servlets, etc.) deployed to the server 102 to handle the incoming requests 112 and perform work. An optional third set of address spaces (not shown) corresponds to one or more adjunct regions, which are specialized servant regions that interface with service integration buses to provide additional services, e.g., messaging services within the distributed platform.
After the servants 108A, 108B, 108C execute the units of work 120 (e.g., individual units of work 120A, 120B, 120C) and generate responses 124 (e.g., individual responses 124A, 124B, 124C), the responses 124 are then relayed back to the controller 104 and onto the client 114. If required, the WLM Enclave 116 provides a key avenue for easy vertical scaling to handle more work requests. On distributed platforms, this type of vertical scaling can be tedious, e.g., because it requires clustering and redefining of incoming ports and address spaces. In the case of multiple servants, each servant has its own unique heap space in addition to its own address space and is considered a unique Java Virtual Machine (JVM).
Java-based web applications can be built in J2EE, which is a platform-independent, Java-centric environment for developing, building and deploying web-based enterprise applications online. The J2EE platform includes a set of services, application programming interfaces (APIs), and protocols that provide the functionality for developing multi-tiered, web-based applications. The J2EE Management Specification is a Java Specification Request, JSR-77, that defines an interface for accessing management information. The goal of JSR-77 is to abstract the fundamental manageable aspects of the J2EE architecture to provide a well-defined model for implementing instrumentation and information access. In addition, JSR-77 defines a standardized API for interoperating with J2EE components that participate in the monitoring and control of the J2EE platform's resources. One of the key features of JSR-77 is its ability to aid in extracting information via management objects. JSR-77 is founded upon Java Management Extensions (JMX), which utilizes the underlying Management Beans (Mbeans) of a J2EE-compliant server. MBeans are virtual objects running inside a server that provide methods to display attributes, operations and notifications providing statistical data.
FIG. 2 is a prior art schematic diagram of an exemplary Performance Monitoring Infrastructure (PMI) architecture 200 of a WAS on z/OS. The PMI architecture 200 includes PMI clients 204 and a server 208 which are in electronic communication with each other. The PMI architecture 200 provides server-side monitoring and a client-side API to retrieve performance data, maintaining statistical data within the entire WAS domain (which can include one or more servers). Each server organizes PMI data into modules (e.g., modules 212, 216, 220, 224) and sometimes submodules. The implementation of JSR-77 in WAS is implemented via the PMI. The PMI framework includes the PMI service, which should be enabled for PMI data to be collected. A given WAS cell can have multiple nodes, typically across different logical partitions, and each node can have multiple servers in the node. In the case of z/OS, each of the servers can also have multiple servants as part of the server, where each servant is a unique address space or JVM with its own attributes.
PMI “modules” or “resource modules” can represent categories for which data is collected and reported via the client API for certain system resources. The resources can include a JVM including one or more servants 214 (e.g., 214A, 214B, 214C), a ThreadPool 216, a JDBCProvider 220, and other statistics provider modules 224, such as Connection Pools for JDBC, and/or JCA/MQ.). Each of these modules has a corresponding MBean (for example, the jvmRuntimeModule is the corresponding module for the JVM MBean). Some of these modules also include submodules: for example, the ThreadPool module 216 includes submodules such as the ORB Thread Pool and WebContainer Thread Pools (not separately depicted). The Performance MBean (Perf MBean) 228 permits the PMI clients 204 to configure the PMI Service for the servers and facilitates collection of data counters (e.g., statistics) via the PMI Modules and Submodules of the servers. The server 208 itself has a Server Mbean 232, which provides server level attribute information (e.g., process ID, name of the cell, etc.) and operational abilities to start and/or stop all the servants of a server. However, JSR-77 leaves it up to specific vendors (e.g., JBoss, WebLogic, IBM, etc.) to implement details of different statistics and metrics that they want to provide through their individual and unique implementations.
WAS for z/OS's architecture (including the control region and servants within the same server as shown above in FIG. 1) follows a separate architecture from typical distributed platforms. Traditional JMX clients utilize the Perf MBean 228 of a given server 208 to collect performance metrics, which in the case of z/OS does not provide information about multiple servants and their details, such as the heap size or the current total free heap. In fact, in the case of a multi-servant JVM, the statistics of the control region are incorrectly added to the first servant of a JVM, rendering the statistics relayed by traditional clients (e.g., Tivoli Performance Viewer) inaccurate. The J2EE specification inherently cannot address vendor-specific features, which is why further standardization has been developed through the Java Specification Request.
Any WebSphere application server can have MBeans that either do not provide any statistics or that have an attribute called “StatisticProvider” set to true (JSR77.6.2). The Perf MBean can collect these JSR-77 compliant PMI statistical data from the individual MBeans and store them in a nested structure that can provide all PMI data with counters for all of the MBeans in the server. The stats attribute from the stats subinterface (JSR77.6.10) of an individual MBean & Statistic subinterfaces (JSR77.6.4) of the Perf MBean provide the necessary methods to retrieve this information, which are widely used by vendors for monitoring the performance and health of the servers.
For JVMs in this environment, the jvmRuntimeModule of the JVM MBean provides the following counters with the “BASIC” level of PMI Service: (1) HeapSize (type=BoundedRangeStatistic); (2) UpTime (type=CountStatistic); (3) UsedMemory (type=CountStatistic); (4) ProcessCpuUsage (type=CountStatistic). Different types of statistical objects (CountStatistic, TimeStatistic, RangeStatistic, BoundedRangeStatistic and BoundaryStatistic) are part of JSR-77. IBM publishes the Java methods to get values for the different types and counters of the Statistic objects that can be used for Performance Monitoring.
Much of the PMI Architecture on z/OS is similar to the distributed platforms; however, since a single server can have multiple servants the current PMI architecture and JSR-77 implementation do not capture the JVM memory details, which are not covered in the specifications. Moreover, there are no published APIs for extracting the heap statistics of servant JVMs within a server via the PMI architecture on z/OS. The JVM stats attribute of a server and the Perf MBean Statistic attribute of the JVM MBean currently report only the counters for the first servant JVM of the server. These values are erroneous, since the UsedMemory and HeapSize of the controller are added to the counters that are reported for the JVM MBean. Thus, PMI architecture does not provide the means to monitor the performance of servant JVMs of a server on z/OS. Commercial and publicly available tools (which are almost always Java-based) utilize the Perf MBean method of extraction of counters statistics, since all available statistics can be extracted with just one JMX call to the Server MBean.
These deficiencies result in meaningful practical consequences for monitoring of distributed computing resources. For example, memory leaks in distributed computing architectures and/or thread pool saturation of various Database, Messaging and Request Broker resources, which can go unnoticed or misunderstood under the current regime, result in large problems for enterprise industries. Collection of such key performance metrics can also help enterprises plan for capacity and analyze trends for better predicting resource usage at various time periods of a day, month or year leading to performance optimization and cost savings. The historical data collected via the overall technology also adds capability to utilize machine learning and artificial intelligence for creating self-healing computing systems.